|
|
|
|
|
|
|
Puzzle 31
File Operations, Part 2 |
|
|
|
|
|
|
|
|
The ShFileOperation looks so innocent at first glanceonly one parameter. But as you saw in the last puzzle, that parameter is a structure of nearly nightmarish complexity: |
|
|
|
|
|
|
|
|
Type SHFILEOPSTRUCT
hwnd As Long
wFunc As Long
pFrom As String
pTo As String
fFlags As Integer
fAnyOperationsAborted As Long
hNameMappings As Long
lpszProgressTitle As String ' only used if FOF_SIMPLEPROGRESS
End Type |
|
|
|
|
|
|
|
|
And if you thought you could sleep peacefully after solving that last puzzle, I have news for you: The nightmare has just begun. |
|
|
|
|
|
|
|
|
The ShFileOperation function supports a feature you've probably seen many times when using Windows Explorer. What happens when you copy a file to the clipboard and paste it into a directory window where a file of the same name already exists? The file is automatically renamed to something along the lines of ''Copy of . . .". The ShFileOperation function performs an automatic file rename if you specify the constant FOF_RENAMEONCOLLISION in the fFlags parameter. |
|
|
|
|
|
|
|
|
But if a function is going to automatically rename files, there should be a way for the application to determine which files have been renamed. This is accomplished using Name Mappings. The hNameMappings field of the SHFILEOPSTRUCT is loaded with information about the files that were renamed when the FOF_WANTMAPPINGHANDLE constant is specified in the fFlags parameter. |
|
|
|
|
|
|
|
|
The Win32 SDK defines the use of the FOF_WANTMAPPINGHANDLE constant as follows: |
|
|
|
|
|